Bank card and response process to a transaction request

ABSTRACT

The invention relates to a bank card ( 100 ) comprising a presentation surface of a pictogram ( 120 ) coding at least one item of information for executing a transaction.

TECHNICAL FIELD AND PRIOR ART

The invention relates to the field of secure payment means, such as forexample bank cards, especially microcircuit bank cards.

When a transaction is made in the absence of a payment terminal capableof reading the card by itself, the holder of the card must input hiscard number on a keypad, and often the security number of the card andthe validity date of the latter. This operation is fastidious andrequires the user to concentrate and not input incorrect numbers whichare long.

Document US2010/0008535 discloses a portable electronic device formaking payment by bank card simply by optical reading of the surface ofthe card. The device can be a mobile telephone and utilises recognitionof characters printed on the card by means of a camera, application ofsegmentation of the surface of the card and recognition of characters onthe different segments.

Document WO01/58080 also discloses a payment card fitted with aultrasonic transducer communicating with any device fitted with amicrophone and/or loudspeakers so as to allow secure authentication ofthe card in the absence of a card reader. In the same document, abarcode reader is also fitted with such a transducer and communicates inthe same way. It is used for reading merchandise barcodes in a shop andconnecting to the web site of the merchandise manufacturer, so as to askabout the benefit of promotional offers.

The disadvantage of these different solutions is primarily first that ofbeing minimally secure and difficult to utilise for a busy user who isobliged to position his card precisely in front of the camera, andsecondly is that it needs specific equipment. There is therefore a needfor secure remote payment solutions which are easy and quick to use. Forthis, a card is proposed according to claim 1 and a process according toclaim 8.

SUMMARY OF THE INVENTION

The invention consists of a bank card comprising a presentation surfaceof a pictogram coding at least one item of information for executing atransaction. This information can be a number of the card, a validitydate of the card, a name or first name of an owner of the card, acategory identifier of a transmitter of the card, an identifier of atransmitter of the card, a security code of the card, or a one-timepassword.

According to a particular characteristic, the pictogram is a barcode,for example a 2D code, for example a QR code (Quick Response), or also adynamic pictogram.

According to an advantageous characteristic, the card comprises acontroller for generating a pictogram valid for a single transaction.

According to various embodiments of the invention, the surface is an LCDscreen, or a layer synthetic printed or etched material, included in thecard body or attached for example by adhesion.

The pictogram preferably codes an address of a transaction server.

The invention also consists of a response process to a transactionrequest comprising steps consisting of receiving a transaction requestcomprising a pictogram coding at least one item of information forexecuting a transaction and complementary information, extracting fromthe pictogram said information for executing a transaction, and as afunction of said information for executing a transaction and of thecomplementary information, as well as predefined authorisation rules,sending an authorisation or a refusal in response to the transactionrequest.

The process is at least partially executed by a server connected to anextended telecommunications network, or by a payment terminal having akeypad and a camera, or even by a mobile electronic unit having a keypadand a camera.

According to an embodiment, the process also comprises the display on ascreen of an input box for an alphanumeric chain constituting thecomplementary information.

In a variant, the predefined authorisation rules comprise a ruleaccording to which authorisation is given as a function of a result of acomparison test applied to the complementary information.

According to a particular mode, the process comprises sending a messageaddressed to a message service of an owner of payment means comprising aone-time identification element, then receipt of an identificationelement provided by a requester of the transaction request andcomparison of the one-time identification element and of theidentification element provided.

The process can also comprise sending at least one characteristic of thetransaction addressed to a message service of an owner of payment means,then receipt of an order form signed by a requester of the transactionrequest and authentication of a signature of the order form.

Finally, in an embodiment, said information for executing a transactionis a one-time password.

Therefore, of other advantages cited by way of non-limitation, theinvention allows the deployment of a contactless bank payment solutionat less cost because of equipment for input and information processingalready widely deployed in user devices or individual public equipment(mobile telephones, computers, tablets equipped with camera).

It also implements a secure and contactless payment solution which isquick to use for bank transactions. The user avoids the fastidious stepof inputting banking information, or information for executing atransaction. He is also protected against possible fraudulent copy ofbanking information in alphanumeric form on the card which, in theabsence of a pictogram coding it, must be recopied during use of thelatter in commerce.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a card according to an embodiment of the invention.

FIG. 2 shows an element generated during use of a card such as thatpresented in FIG. 1.

FIG. 3 shows an arrangement used for executing a process according to anembodiment, and cooperating with a card such as presented in FIG. 1.

FIG. 4 shows a detail of the card of FIG. 1.

FIG. 5 shows an aspect of a response process according to an embodimentof the invention.

FIG. 6 shows a mobile electronic unit used for executing a processaccording to an embodiment.

FIG. 7 shows the mode of use of the invention by the owner of the cardof FIG. 1.

FIGS. 8 to 11 show use scenarios of the invention.

FIG. 12 shows an alternative to the embodiment presented in FIG. 5.

DETAILED EXPLANATION OF THE INVENTION

FIG. 1 illustrates a bank card 100 according to the invention. This is acard of dimensions 54×85.6×0.76 mm, but other dimensions can be used. Itcomprises a microcircuit 110 including a controller and memory in asecure assembly with flush contacts.

On one of its surfaces, here the surface on which the contacts of themicrocircuit 110 are flush, the card also presents a two-dimensionalbarcode 120, responding to the QR standard (Quick Response). Othertwo-dimensional barcode standards could be used, and a one-dimensionalbarcode is also a possible variant. A pictogram responding to othercoding conventions can also be used, provided it codes information for atransaction.

This barcode 120 is affixed to the surface of the card via an attachedsticker, ink printing on the upper layer of the card, laser etching ofthe upper layer, or laser processing of a photosensitive layer coveredby a protective layer or another physical action which forms a visiblediagram by a reading tool (a camera, for example) external to the card.The barcode 120 can be affixed to any one of the faces of the card, forexample to the front face near bank-related elements presented inalphanumeric form, or to the rear face near bank-related elementspresented in the form of a magnetic strip.

In some embodiments, the card can have, in alphanumeric form and on thissame surface or on its other surface, the number of the card accordingto the standard ISO/IEV 7812. This is a succession of 16 digits (eachbetween 0 and 9), grouped in blocks of 4 digits. The card can also showthe expiration month and the identity of the owner, in the form of firstname then last name. These different elements constitute bank-relatedelements presented in alphanumeric form 130.

The barcode 120 can be scanned by a barcode reader connected to adaptedsoftware. In an embodiment it codes the information presented in FIG. 4.

First of all, the barcode 120 codes an html command 121 (html means“hypertext markup language”) describing a frame 210 illustrated in FIG.2, and pre-filled information 220 to be displayed in the frame 210. Thepre-filled information 220 can be indicated explicitly in the htmlcommand 121 or alternatively only an address memory where the withdrawercan be indicated in the command.

The barcode 120 can also code an address 122 identifying a server 320 ona network (illustrated in FIG. 3). Here it is an address on the Internetnetwork, but it could also be a telephone link to an audio-telephoneidentification service, or a telephone link to an SMS server.

Finally, in some embodiments the barcode 120 also codes encryptedinformation 123 useful for a local control operation, to be explainedhereinbelow.

The structure of the frame 210 is presented in FIG. 2. The frame 210 isdisplayed on a screen 200 of a terminal used for a transaction. It showsdifferent pre-filled information 220, such as the number of the card,its expiration date, the security code of the card (3-digit code oftenaffixed to the rear of bank cards), and amounts corresponding to twodifferent levels of authorisation.

The first is a maximum transaction amount not requiring any particularcontrol operation (called authorisation level 1), and the second is amaximum level beyond which no transaction is authorised with the card100 (called authorisation level 2). The frame 210 also shows the name ofthe sending bank of the card 100 and a dialogue box (input box 230) forentering a password. Finally, the frame includes two buttons—OK andCANCEL (or “agree” and “cancel”).

The amount of the transaction is either to be filled in by the user in adialogue box, or prefilled, as is illustrated in FIG. 2, since the htmlcode of the frame 210 provides for obtaining this amount from theterminal memory used for the transaction.

FIG. 3 illustrates a reading terminal 300, used for the transaction, andwhich is connected by a network 310 to a server 320.

The reading terminal 300 comprises a keypad 280 (or at least aman-machine interface for inputting an alphanumeric chain), a camera 302for reading barcodes 2D, a SIM card (Subscriber Identification Module309) and a control unit 305 comprising especially local software 307 forprocessing transaction requests. A transaction counter 308 is alsopresent in the control unit 305 or alternatively in the SIM card 309 forgreater security (alternative not illustrated). In a variant, the SIMcard is included in the control unit 305. The screen 200 forms part ofthe reading terminal 300.

The server 320 can comprise in a memory a reference password 325associated with the owner of the card 100 and a messaging address 327associated with the owner of the card 100.

FIG. 5 shows message transfers between the control unit 305 (or the SIMcard 309), the server 320 and a message service 500 of the owner of thecard 100. This message service is for example displayed on the screen ofa mobile telephone 510 illustrated in FIG. 6. This can be a messageservice for SMS or MMS messages on the GSM network, or a message serviceof email type consultable on a mobile telephone or a personal computerconnected to the Internet, via a wire or cellular connection.

By way of cryptographic means present in the SIM card 309, the controlunit 305 performs a signing step 409 of a request 410 which is sent tothe server 320, the address 122 of which is known by reading of thebarcode 120. The request 410 comprises the amount of the transaction.The signature 409 is based on the value of the transaction counter 308,which is also sent unencrypted in the request.

The server 320 verifies whether the signature of the request isauthentic. Then, if this is the case and if the amount of thetransaction exceeds the maximum transaction amount needing no particularcontrol operation (authorisation level 1), the server 320 sends amessage 420 to the message service of the owner of the card 100 (theaddress 327 of which is known from the server 320), asking forconfirmation and comprising a token, which can be coded. The token isdecoded if necessary by the microcircuit card 515 (SIM card) of themobile terminal 510 and displays on the screen of the latter. It can beconstituted by an alphanumeric chain.

The control unit 305 is also prevented from sending a token by theserver 320 during a step 430 comprising an initial response of theserver. The owner of the message service can then submit the token tothe control unit 305, for example via the keypad 280. The submittedtoken is then transmitted by the control unit 305 to the server 320during a step 440. If the server 320 notices that this submitted tokenis identical to that previously transmitted to the message service 500,it validates the transaction and informs the control unit 305 thereofduring a step 450 comprising a second response of the server.

If the transaction does not exceed the maximum transaction amountneeding no particular control operation (authorisation level 1), aresponse step 430 from the server to the control unit 305 is performed,indicating that the transaction has been processed.

The process according to this embodiment is illustrated in FIG. 7, fromthe viewpoint of the user. In this process, determination of thetransaction during a step 700 is first carried out, using the readingterminal 300. This determination can be done by selection and validationof an online Internet purchase (use shown in FIGS. 8 and 9), or use ofan application dedicated to purchases in a shop (supermarket or networkof shops equipped with codes legible by camera, as is shown in FIG. 11),or by a merchant having a payment terminal (use shown in FIG. 10). Theinformation obtained is stored in memory of the control unit 305.

The holder of the bank card 100 scans the barcode 120 with the camera302 during a step 710. The control unit 305 extracts the code 121 of theframe 210 and the latter is displayed on the screen 200, for someprefilled fields using the information fixed during the determinationstep of the transaction 700, recovered in the memory of the readingterminal 300.

Local control of the identity of the user is also carried out via anapplet in a secure element. This constitutes a step 720 during which theuser is invited to enter his password in the input box 230. The userthen agrees to the transaction by pressing the “OK” button after havingverified the prefilled information 220. The password entered into theinput box 230 is compared to that contained in the encrypted information123.

Instead of password verification, other secure solutions can beexecuted, such as verification of biometric data, a PIN code, or a listof choices proposed on a man-machine interface, this information beingpresent in all encrypted information 123.

Control can also be carried out remotely by the server 320, using thereference password 325. In this case, the request 410 comprises transferof the password entered by the user into the dialogue box.

In FIG. 7, the left area corresponds to a scenario without theparticular verification operation being performed, and that on the rightto a scenario with the particular verification operation. The additionalsteps in this area are those shown in dotted lines in FIG. 5.

A test 730 is conducted to determine whether the amount of thetransaction exceeds authorisation level 1. This test is conducted eitherby the control unit 305 (in which case the result of the test isincluded in the request 410) or by the server 320 (in which case theserver 320 previously stores the authorisation level associated witheach card 100). If the amount of the transaction exceeds authorisationlevel 1, the sending step 420 of a message to the message service of theowner is performed by the server 320. The user consults his messageservice 500 during a step 740, discovers the token and recopies thelatter into the reading terminal 300 using the keypad 280, during a step750.

In a variant illustrated in FIG. 12, the control unit 305 performs asignature step 1409 of a request 1410 which is sent to the server 320 byway of cryptographic means present on the SIM card 309, the requestcomprising the amount of the transaction.

The server verifies the authenticity of the signature. Next, if theamount of the transaction exceeds the maximum transaction amount notneeding a particular verification operation (authorisation level 1), theserver 320 sends a message 1420 to the message service of the owner ofthe card 100 (whereof the address 327 is known to the server), askingfor confirmation. This message comprises at least one characteristic ofthe intended transaction, and preferably comprises the nature of thegoods or service bought, the quantity, the unit price and the totalprice.

The owner of the message service responds to this by entering hispassword or a previously agreed response code and by addressing via themassage service a response 1430 including the password or the code, aswell as the characteristics of the transaction taken from the precedingmessage. This response constitutes a signed purchase order. If thesignature of the order form (here, the password) is authenticated by theserver 320, the latter reacts by sending an acceptance message 1440 ofthe response addressed to the control unit 305.

If the amount of the transaction does not exceed the authorisation level1, the server 320 sends the acceptance message 1140.

FIGS. 8 to 11 illustrate modes of use of the invention.

A first mode of use is a purchase by means of a mobile telephone havinga camera and connected to the Internet, comprising the reading terminal300. This is illustrated in FIG. 8, where the user of the telephonescans the barcode of the card 100 with the camera. He is asked for apassword in the input box 230 of the frame 210. If the password isentered correctly by the user and if the amount of the transaction isless than the authorisation level 1, the transaction is finalised onthis basis, without further verification.

A second mode of use is a purchase by means of a fixed terminal(typically a computer), or a touch tablet, comprising the readingterminal 300 (illustrated in FIG. 9) having a webcam and Internetaccess. In this embodiment, the reading terminal 300 does not include aSIM card 309, and the request 410 or 1410 is not signed.

A third mode of use, illustrated in FIG. 10, is a purchase in a point ofsale having a conventional payment terminal for bank cards withmicrocircuit and operating by contact. Such a terminal includes keypadand screen assembly 9100 adapted for inputting a PIN code. According tothe invention a camera 9200 is added to the latter for scanning thebarcode. The assembly of the conventional terminal and the camera, aswell as the adequate software application constitutes the readingterminal 300. In this mode of use, the function of the conventionalcontact reading terminal 9100 of the microcircuit is not used.

A fourth mode of use, illustrated in FIG. 11, is a purchase made in ashop or a restaurant. The vendor (here a restaurant) is identified by abarcode which is scanned by the camera of a mobile telephone comprisingthe reading terminal 300. The mobile telephone acting as terminal 300 isthen used to scan the barcode 120 of the card 100. An application 350recorded in the mobile telephone makes the link between the twoidentifiers and organises the transaction.

In another embodiment, the barcode 120 is presented on a liquid crystalscreen included in the card body. The barcode can be a dynamic code,generated as per the logic rules executed by a controller included inthe card, and preferably in a secure circuit of the card, such asmicrocircuit 110. The barcode represents one-off passwords, delivered ateach transaction attempt. The server 320 verifies the password either byverifying it on the basis of transmitted data, or on the basis of apre-recorded list. The dynamic code can be generated from thetransaction counter 308.

The invention is not limited to the particular embodiments presentedhere, but extends to all variants within the scope of the claims.

1. A bank card comprising a presentation surface of a pictogram codingat least one item of information for executing a transaction.
 2. Thebank card according to the preceding claim, in which the at least oneitem of information is a number of the card, a validity date of thecard, a name or first name of an owner of the card, a categoryidentifier of a transmitter of the card, an identifier of a transmitterof the card, a security code of the card, or a one-time password.
 3. Thebank card according to claim 1, in which the pictogram is a barcode, forexample a 2D code, for example a QR code.
 4. The bank card according tothe preceding claim, in which the pictogram is a dynamic pictogram. 5.The bank card according to claim 1, in which the card comprises acontroller for generating a pictogram valid for a single transaction. 6.The bank card according to claim 1, in which the surface is an LCDscreen, or a layer synthetic printed or etched material, included in thecard body or attached for example by adhesion.
 7. The bank cardaccording to claim 1, in which the pictogram codes an address of atransaction server.
 8. A response process to a transaction requestcomprising steps consisting of receiving a transaction requestcomprising a pictogram coding at least one item of information forexecuting a transaction and complementary information, extracting fromthe pictogram said information for executing a transaction, and as afunction of said information for executing a transaction and of thecomplementary information, as well as predefined authorisation rules,sending authorisation or refusal in response to the transaction request.9. The response process according to the preceding claim, in which theprocess is at least partially executed by a server connected to anextended telecommunications network.
 10. The response process accordingto claim 8, in which the process is at least partially executed by apayment terminal having a keypad and a camera.
 11. The response processaccording to claim 8, in which the process is at least partiallyexecuted by a mobile electronic unit having a keypad and a camera. 12.The response process according to claim 8, in which the process alsocomprises display on a screen of an input box for an alphanumeric chainconstituting the complementary information.
 13. The response processaccording to claim 8, in which the predefined authorisation rulescomprise a rule according to which authorisation is given as a functionof a result of a comparison test applied to the complementaryinformation.
 14. The response process according to claim 8, in which theprocess comprises the sending of a message addressed to a messageservice of an owner of payment means comprising a one-timeidentification element, then receipt of an identification elementprovided by a requester of the transaction request and comparison of theone-off identification element and of the identification elementprovided.
 15. The response process according to claim 8, in which theprocess comprises the sending of at least one characteristic of thetransaction addressed to a message service of an owner of payment means,then receipt of an order form signed by a requester of the transactionrequest and the authentication of a signature of the order form.
 16. Theresponse process according to claim 8, in which said information is aone-time password.